With the continued development of Information Technology (IT) and integrated environments, electronic document archiving continues to grow in popularity. In one implementation, an organization can maintain its own content storage system, while using a third party system (e.g., an indexing system) to create an index that is stored in the indexing system (e.g., SAP) and later access documents. In this implementation, documents will be stored/archived in the content storage system from the indexing system using a document and index transfer tool/application that integrates the indexing system with the content storage system. One example of such a tool is Commonstore, which is commercially available from International Business Machines Corp. (IBM) of Armonk, N.Y.
In general, when a document is desired to be archived, it will be “attached” using the document and index transfer tool (i.e., because you can use an indexing system such as SAP to store documents into a content storage system without having to transfer any index information). The transferring of index information is generally necessitated by the need to be able to access the document outside the indexing system.
In any event, each document to be archived is typically assigned a unique identifier (e.g., a UID such as a hexadecimal string) in the indexing system prior to being archived in the content storage system. This allows the document to be later referenced/accessed from the indexing system using the UID. In addition, various document “attributes” can be specified. For example, if the document is a contract for services, possible attributes can include a contract number, a contract amount, a contact person, etc. These attributes will be transferred to the content storage system along with the actual document for the reasons described above.
This allows a layperson to access a document using its attributes instead of having to recall the document's unique identifier both inside and outside of the indexing system. In any event, when a document and its corresponding attributes are archived, an archival date (i.e., the date on which it was archived) is saved.
On occasion, document attributes may change. For example, a document's contact person may be changed. Such changes can be input into the indexing system using the index transfer tool, and then transferred to the content storage system so that the archived document's attributes can be changed accordingly. Unfortunately, current approaches result in the transfer of an overly-voluminous amount of information. Specifically, the transfer of attributes from the indexing system to the content storage system is currently based on the original archival date for the corresponding document. For example, if a document and its attributes are archived on Jan. 1, 1970, an archival date of Jan. 1, 1970 will be assigned. If the attributes for that document are changed on Jan. 1, 2006, those changes must be propagated to the content storage system. However, the existing system bases the transfer of changes on the original archival date. Therefore, all attributes for all documents that were archived between Jan. 1, 1970 and Jan. 1, 2006 will be transferred. Such an approach is inefficient and can waste valuable bandwidth.
In view of the foregoing, there exists a need for an approach that solves at least one of the deficiencies in the existing art.